Add Dependabot configuration and stop committing composer.lock - #42
Merged
Conversation
Actions are referenced by floating major tags, so a moved tag runs new code in CI with repository credentials. Weekly version updates keep them current, grouped into one pull request. Composer is set to security updates only. Consumers resolve against composer.json and never see this package's composer.lock, so routine lock bumps would be noise; open-pull-requests-limit: 0 disables version updates without affecting the security updates enabled on the repository.
|
Warning Review limit reachedNext included review available in 19 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Composer ignores a dependency's lock file, so this one never reached consumers. Comparable bundles — Nelmio, maker-bundle, DoctrineBundle, api-platform — do not commit one either. It was also nearly inert here: the test matrix runs composer update against each Symfony version and never read it, so it pinned only the Lint job's static analysis tools. What it did do was hold vulnerable transitive Symfony versions, which is the entire content of the eight advisories that appeared when Dependabot alerts were switched on. A fresh resolve reports no advisories. Lint now runs composer update. The cache key already hashes composer.json, so it needs no change.
stixx
changed the title
supports() tested `$result instanceof Traversable` after is_object(), but Traversable is an interface, so every implementation is an object and the earlier branch already returned true. PHPStan 2.2 reports it as instanceof.alwaysFalse. Behaviour is unchanged: the existing 'Traversable' case in supportsProvider, which passes an ArrayIterator and expects true, still passes. Surfaced by dropping composer.lock — Lint had been pinned to PHPStan 2.1.33 and now resolves 2.2.10, which added this rule.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Enables Dependabot on the repository and removes the committed
composer.lock.Dependabot
Alerts and security updates were both off — not just the auto-PRs, the alerting itself. Both are now enabled in the repository settings; this adds the config for everything else.
github-actions, weekly. The workflow pins actions to floating major tags (actions/checkout@v5,shivammathur/setup-php@v2,actions/cache@v4). A moved tag executes new code in CI with repository credentials. Updates are grouped into one PR.composer, security only.open-pull-requests-limit: 0disables version updates; security updates are governed by the repository setting and still apply.Remove
composer.lockLibraries don't commit a lock file — Composer ignores a dependency's lock, so it never reached a consumer. Nelmio, maker-bundle, DoctrineBundle and api-platform/core all omit it.
It also did almost nothing here. The test matrix runs
composer updateper Symfony version and never read it; it pinned only the Lint job's static-analysis tools. Meanwhile it held vulnerable transitive Symfony versions, which is the whole of the 8 advisories currently shown on the default branch — all transitive underframework-bundle, none a directrequire, so consumers were never affected. Removing the file clears them; #37–#41 become obsolete.Lint now runs
composer update. The cache key already hashescomposer.json.JsonSerializedResponder::supports()Unpinning the tools moved Lint from PHPStan 2.1.33 to 2.2.10, which flags:
Traversableis an interface, so every implementation is an object and the first branch already returnedtrue. Removed, with its import. Behaviour is unchanged — the existing'Traversable'case insupportsProviderpasses anArrayIteratorand still expectstrue.Verification
A clean clone without the lock reports
No security vulnerability advisories found, resolves the five previously-flagged packages tov8.1.5, and passes 224 tests. All six CI checks green.Trade-off
A phpstan or php-cs-fixer release can now turn Lint red without a code change, as it did in this PR. Tightening those two
require-devconstraints is the lever if that becomes disruptive.Not included
@<sha> # v5), which Dependabot also maintains — separate, larger diff.composer audit's"block-insecure": false, set in 0.11.1 so the solver would resolve. Worth re-testing now that a fresh resolve is clean.